1. Field of the Invention
The present invention relates to a mobile communication system, and more particularly to a method and apparatus for transmitting/receiving an MAC (Media Access Control) packet in a mobile communication system.
2. Description of the Related Art
The UMTS (Universal Mobile Telecommunication Service) system is a 3rd generation asynchronous mobile communication system which is based on European mobile communication systems, that is, GSM (Global System for Mobile Communications) and GPRS (General Packet Radio Services), and employing a WCDMA (Wideband Code Division Multiple Access) scheme.
The 3GPP (3rd Generation Partnership Project) responsible for the UMTS standardization is currently developing LTE (Long Term Evolution) as a next generation UMTS system. LTE, with an aim of commercialization by around 2010, is technology for implementing high-speed packet-based communication at data rates of about 100 Mbps. To this end, various plans are under discussion, including a plan to reduce the number of nodes located on a communication path by simplifying a network architecture, a plan to approximate wireless protocols to a radio channel as close as possible, and so forth.
FIG. 1 illustrates an example of the structure of a next generation mobile communication system. FIG. 1 illustrates a system structure based on the UMTS system.
Referring to FIG. 1, evolved radio access networks (hereinafter referred to as “E-RAN”) 110 and 112 have a simplified two node structure of evolved Node Bs (hereinafter referred to as “ENB” or “Node B”) 120, 122, 124, 126 and 128, and anchor nodes 130 and 132, as illustrated therein. User equipment (UE) 101 is connected to an internet protocol (IP) via the E-RANs 110 and 112.
The ENBs 120 to 128 corresponds to an existing Node B of the UMTS system, and is connected to the UE 101 over a radio channel. Unlike an existing Node B, the ENBs 120 to 128 perform more complex functions. In LTE, all user traffic, including a real-time service through an IP, such as a VoIP (Voice over IP) service, is serviced via a shared channel, and the ENB performs scheduling after collecting situation information of UEs.
In order to enable a maximum transmission speed of 100 Mbps, LTE is expected to employ an orthogonal frequency division multiplexing (OFDM) scheme as radio access technology with a bandwidth of 20 MHz. The LTE is also expected to apply an adaptive modulation and coding (AMC) scheme in which a modulation scheme and a channel coding rate are adaptively determined to the channel state of a UE.
Similar to HSDPA (High Speed Downlink Packet Access) or E-DCH (Enhanced-uplink Dedicated Channel), LTE uses HARQ (Hybrid Automatic Retransmission Request) between the ENBs 120 to 128 and the UE 101. However, since various levels of quality of service (QoS) requirements cannot be satisfied by the HARQ alone, an upper layer may perform a separate ARQ (outer-ARQ), which also takes place between the UE 101 and the ENBs 120 to 128.
FIG. 2 illustrates the structure of an LTE protocol.
As illustrated in FIG. 2, RLC (Radio Link Control) entities 220, 225, 230, 260, 265 and 270 are be established for each upper layer 205, 210, 215, 275, 280 and 285.
The RLC entity resizes upper layer data to an appropriate size, and performs an automatic retransmission request (ARQ) operation for the resized data. The data resized to an appropriate size by the RLC entity is referred to as an RLC protocol data unit (PDU).
In LTE, transmitting (Tx) RLC entities 220, 225 and 230 construct RLC PDUs 233 in such a manner as to have a size transmittable in an MAC (Media Access Control) layer at a corresponding point in time. Thus, the size of an RLC PDU 233 may vary with a channel situation, a resource allocation situation, or the like.
If a lower layer notifies a Tx RLC entity 220, 225 or 230 of the size of an RLC PDU to be transmitted in the next transmission time interval (TTI), the Tx RLC entity 220, 225 or 230 generates an RLC PDU by splitting or joining upper layer data in conformity with the notified size and inserting an RLC PDU header. The RLC PDU header may include serial number information, etc.
A Tx MAC entity 240 multiplexes RLC PDUs submitted from the Tx RLC entities 220, 225 and 230 to thereby generate an MAC PDU 243. Since RLC PDUs generated by several RLC entities may be multiplexed into one MAC PDU, multiplexing information for the RLC PDUs is inserted into an MAC PDU header. Information included in the MAC PDU header will be described in detail below with reference to FIG. 3.
The MAC PDU generated by the Tx MAC entity 240 passes through an HARQ process, and then is transmitted to a receiving side.
A packet actually transmitted over a radio channel is also referred to as a transport block 247. However, one MAC PDU is mapped to one transport block, that is, these two are different only in name and actually denote the same object. In the following description, a transport block and an MAC PDU will be used interchangeably.
For an HARQ operation, information necessary for transport block decoding is transmitted together with a separate control signal when a transport block 247 is transmitted from a Tx HARQ entity 245. This information includes information indicating the size a transport block (TB size) 249, information on an MCS (Modulation and Coding Scheme) applied to the transport block (MCS Info) 248, etc.
Since a transport block and an MAC PDU denote the same object, the information 249 indicating a TB size is not different from information indicating the size of an MAC PDU.
Upon successfully receiving a transport block 247, a receiving (Rx) HARQ entity 250 forwards an MAC PDU to an Rx MAC entity 255. The Rx MAC entity 255 separates an RLC PDU from the forwarded MAC PDU by using information included in an MAC PDU header, and forwards the separated RLC PDU to an appropriate Rx RLC entity 260, 265 or 270.
As discussed above, one of the important operations of an MAC layer is to multiplex RLC PDUs generated by several RLC entities into one MAC PDU and demultiplex RLC PDUs from an MAC PDU.
FIG. 3 illustrates the structure of an MAC PDU.
Referring to FIG. 3, upon receiving an RLC PDU from an RLC entity, a Tx MAC entity inserts a logical channel ID (LID) and a length (LEN) of the RLC PDU into an MAC PDU header.
Since one LID and one LEN per RLC PDU are inserted, as many LIDs and LENs as RLC PDUs are inserted when a plurality of RLC PDUs are multiplexed into one MAC PDU.
Information included in an MAC PDU header is usually located in the front of an MAC PDU, and thus LIDs and LENs match to RLC PDUs in their order within the header. In other words, the first LID 305 and the first LEN 310 within an MAC PDU header are information regarding the first RLC PDU 325, and the second LID 315 and the second LEN 320 are information regarding the second RLC PDU 330.
For a physical layer operation, the overall length of an MAC PDU is transferred to a receiving side through a separate control signal. Since the overall length of an MAC PDU is a value quantized according to given criteria, padding 335 may also be used in some cases. The padding refers to filling specific bits (usually 0) in remaining parts within a packet so as to achieve the byte-aligned length of a data packet when the data packet is generated.
In some cases, an LEN value indicating the length of an RLC PDU is unnecessary information because the overall length of an MAC PDU is given. For example, if only one RLC PDU is accommodated in an MAC PDU, it is highly probable that the length of the RLC PDU is equal to the length of the MAC PDU, excluding that of an MAC PDU header.
A VoIP packet consists of an IP/UDP/RTP header and a VoIP frame, the IP/UDP/RTP header is compressed to about 1 to 15 bytes through a header compression protocol called ROHC (Robust Header Compression), and the length of the VoIP frame is always constant within a given codec rate. In other words, the length of the VoIP packet remains within a certain range, and thus it is more efficient to use a predetermined value rather than absolute information, such as LEN. Since the length of an RLC PDU in LTE can contain several thousand bytes, an LEN field indicating the length of an RLC PDU has a length of about 10 bits. In contrast with this, since the maximum length of an RLC PDU accommodating a VoIP packet is only several tens of bytes, and the length of a frequently occurring packet can be predicted, it is possible to express most lengths by even small-sized information with a length of about 3 or 4 bits. If a VoIP operates by means of a codec with a variable codec rate, such as AMR (Adaptive Multi-Rate), the number of possible packet lengths significantly increases. Thus, an SID (Size Index), which is collapsed information indicating the length of an RLC PDU, may require many more bits. However, when an MAC PDU header for a VoIP is designed in such a manner that the size of an SID coincides with the operation of the AMR codec, it is possible that the length of the MAC PDU header becomes too large. In a high-speed communication system, such as LTE, an MAC PDU header is byte-aligned, and thus it is grossly inefficient to determine the size of an SID by taking all circumstances into consideration because a one or two-bit increase in the size of an SID may cause one-byte increase in the length of an MAC PDU header.